Universal consumption service

ABSTRACT

In accordance with some implementations, a method for selecting a vendor in accordance with some implementations is disclosed. The method is performed on a server system having one or more processors and memory storing one or more programs for execution by the one or more processors. The server system detects stores one or more vendor profiles, wherein each vendor profile is associated with a particular vendor and includes one or more vendor category scores. The server system then receives a purchase request from a user of the server system, wherein the purchase request includes a product or service to be purchased. The server system then determines a vendor to supply the requested product based on the stored vendor profiles. The server system purchases the requested product from the determined vendor. The server system then arranges for delivery of the purchased product or service.

RELATED APPLICATIONS

This application is claims priority to the following (1) U.S.Provisional Application Ser. No. 61/648,564, filed May 17, 2012,entitled “Progressively Asking for Increasing Amounts of User andNetwork Data”; (2) U.S. Provisional Application Ser. No. 61/648,566,filed May 17, 2012, entitled “Conversational Interfaces”; (3) U.S.Provisional Application Ser. No. 61/648,569, filed May 17, 2012,entitled “Universal Communications Infrastructure”; (4) U.S. ProvisionalApplication Ser. No. 61/648,578, filed May 17, 2012, entitled “TrustGraph”; (5) U.S. Provisional Application Ser. No. 61/648,582, filed May17, 2012, entitled “Universal Consumption Service”; (6) U.S. ProvisionalApplication Ser. No. 61/648,588, filed May 17, 2012, entitled “RewardStructures”; (7) U.S. Provisional Application Ser. No. 61/648,591, filedMay 17, 2012, entitled “System and Method for Social Network BasedReferrals”; (8) U.S. Provisional Application Ser. No. 61/688,655, filedMay 18, 2012, entitled “System and Method for Social Network BasedReferrals”; which are incorporated herein by reference in theirentirety.

This application is also related to the following (1) U.S. applicationSer. No. ______, filed ______, entitled “Progressively Asking forIncreasing Amounts of User and Network Data” (Attorney Docket:020610-5001); (2) U.S. application Ser. No. ______, filed ______,entitled “Conversational Interfaces” (Attorney Docket: 020610-5002); (3)U.S. application Ser. No. ______, filed ______, entitled “UniversalCommunications Infrastructure” (Attorney Docket: 020610-5003); (4) U.S.application Ser. No. 13/769,181, filed Feb. 15, 2013, entitled “TrustGraph”; (5) U.S. application Ser. No. ______, filed ______, entitled“Zero Click Commerce Systems” (Attorney Docket: 020610-5005); (6) U.S.application Ser. No. ______, filed ______, entitled “UniversalConsumption Service” (Attorney Docket: 020610-5006); (7) U.S.application Ser. No. ______, filed ______, entitled “Reward Structures”(Attorney Docket: 020610-5007); which are incorporated herein byreference in their entirety.

TECHNICAL FIELD

The disclosed implementations relate to the field of online commercegenerally and to enhancing optimizing commerce experiences for users inparticular.

BACKGROUND

Over the last two decades, the buying and the selling of productsthrough computer networks such as the Internet has increaseddramatically. A significant portion of all commerce is now conductedonline through the Internet. As the amount of commerce conducted onlinegrows, the number of online commerce vendors also grows. As such, anincreasing number of online vendors compete with each other to offerusers the best user experience. An important way to differentiate fromother online retailers is to provide the most convenient userexperience.

One result of the growth of online commerce is that the sheer number ofvendors and websites can be overwhelming to users who want to purchase aproduct or service. It can be difficult for users to process so muchinformation to find the best product or service from the best vendor fortheir particular needs. Indeed, often users never find out aboutopportunities or vendors that would closely match their needs.

Personal assistants, wedding planners, travel agents, and other consumeragents offer a contractual relationship with the end consumer to helpthem fulfill their consumer needs for products and services, brokeringthe deal with the ultimate product or service providers. For example, awedding planner might arrange for a service or a service provider (e.g.,reserving and contracting a band. Similar to these services, our serviceacts as an Agent on behalf of the consumer to broker a “consumptiveexperience for a product/service combination (broadly defined) that theypay for (most of the time). It would be useful to have a service thatwould curate the large number of products and services available and thevarious vendors to provide the best experience to a user in a waysimilar to the way that personal assistants work or a personal shopper.

SUMMARY

In some implementations, the system described herein, bridges the gapbetween “social” and “commerce” by enabling a universal ability toconsume, irrespective of merchant or product or service, and seamlesslymaking the consumption easy. This allows for the free expression ofsocial intent, while enabling commerce to occur where it is already moststrongly encouraged: from the people we trust.

In some implementations, the system brokers consumptive experiences onbehalf of end consumers, for combinations of products and services,where the consumer registers the intent to consume (and typicallytransacts) with the service, authorizing the service to act as an agenton their behalf to find and coordinate the fulfillment of theconsumptive experience from various service and product providers,merchants, retailers, distributors, dealers, manufacturers, or any othermeans or method of consumptive fulfillment. Products are defined asconsumer objects that can be used or consumed by the purchaser andincludes both physical products (e.g., a chair) and digital products (anapplication, a piece of digital media etc.). Services can include anypurchasable service (e.g., a restaurant reservation or a house painterpainting a normal sized house or any other service).

In some implementations, the service acts like anagent/broker/concierge/personal shopper on behalf of the member, who canexpress their intent to consume a product or service, can provide apayment method, and the agent thereafter ensures that the product and/orservice seamlessly is delivered for the individual. In someimplementations, the service has three main areas of systems andmethods. The first involves analyzing, capturing, and representing theproduct/service intended for consumption. The second involves themanagement of the payment, processing, merchant/vendor relationships,and fulfillment of the product/service. The third covers theoptimization and selection of merchants/vendors/providers to optimallyobtain the best product for the user.

In accordance with some implementations, a method for curating onlinecontent to enhance a user's experience is disclosed. The computer systemdescribed within customizes and curates both products and services andthe vendors that provide those products and services. In someimplementations, the system provides recommendations to a user based on,among other things, the user's preferences, interests, social networkrelationships, trusts and overall product popularity. In addition toproviding product recommendations, once a user has instructed thecomputer system to purchase a particular product or service, thecomputer system assists the user in determining the optimal vendor fromwhich to purchase the indicated product or service.

In some implementations, the product purchase request from a userincludes a vendor preference. In some implementations, the purchaserequest includes a user specified vendor with instructions to use onlythe specified vendor. In other implementations, the purchase requestincludes a user specified vendor, but no instructions to use only thespecified vendor. In some implementations, the level of preference isincluded in the product request and the stronger the level of therequest, the more likely that the computer system will use the specifiedvendor. In some implementations, the purchase request includes either novendor or no stated preference. In this case, the computer systemselects a vendor from the plurality of possible vendors.

In some implementations, the computer system stores a database of vendorprofiles. Each vendor profile includes a plurality of vendor categoryscores. Each vendor category score rates a vendor on a particular aspector attribute associated with providing products to users. For example,vendor score categories includes such categories as average cost,delivery time, delivery cost, consumer satisfaction, distance from theuser, shipping methods, stock status, return policy, and any othercategory relevant to providing products or services to consumers. Foreach product order received, the computer system uses the plurality ofvendor category scores to generate an overall weighted vendor score foreach vendor for each product order. In some implementations, the variousvendor category scores are weighted in accordance with prioritiesassociated with each category score. Once an overall weighted score isgenerated for each vendor, the vendors are ranked in accordance withtheir respective overall weighted vendor score.

In some implementations, the computer system determines a vendor fromwhich to purchase the requested product or service. In someimplementations, the vendor with the highest overall weighted vendorscore is selected. In some implementations, each product is stored in aproduct database and has one or more associated vendors. The computersystem selects the associated vendor stored in the product database. Insome implementations, the user specifies a vendor when submitting theproduct purchase request and the computer system selects the userspecified vendor.

In some implementations, the computer system generates an overall vendorscore for both the user submitted vendor and the plurality of vendorsstored by the computer system. The computer system then compares theoverall vendor score of the user submitted vendor and the highest scoredvendor in the plurality of vendors. If the overall vendor score for thehighest scored vendor of the plurality of vendors exceeds the overallvendor score of the user submitted vendor by at least a predeterminedamount, the computer system selects the highest scored vendor instead ofthe user selected vendor. In some implementations, if the computersystem selects a vendor other than the user submitted vendor, the systemsends a confirmation request to the user prior to purchasing therequested product from the new vendor. If the user responds and rejectsthe new vendor, the computer system reverts to the user selected vendor.

In some implementations, the priorities associated with the vendorcategory scores are determined by the user and submitted with theassociated product purchase request. In some implementations, thecomputer system has default values associated with each vendor categoryand the computer uses the default priority vendor scores when generatingthe overall vendor scores. In some implementations, priorities aredetermined based on past user behavior that has been recorded. Thedetermined priorities are then stored in the user profile. In someimplementations, the computer system purchases the product from theselected vendor and arranges for delivery of the product according tothe user's instruction.

In accordance with some implementations, a method for selecting a vendoris disclosed. The method is performed on a server system having one ormore processors and memory storing one or more programs for execution bythe one or more processors. The server system stores one or more vendorprofiles, wherein each vendor profile is associated with a particularvendor and includes one or more vendor category scores. The serversystem then receives a purchase request from a user of the serversystem, wherein the purchase request includes a product or service to bepurchased. The server system then determines a vendor to supply therequested product based on the stored vendor profiles. The server systempurchases the requested product from the determined vendor. The serversystem then arranges for delivery of the purchased product or service.

In accordance with some implementations, a server system for selecting avendor is disclosed. The server system has one or more processors, andmemory storing one or more programs to be executed by the one or moreprocessors. The one or more programs include instructions for storingone or more vendor profiles, wherein each vendor profile is associatedwith a particular vendor and includes one or more vendor categoryscores. The one or more programs further include instructions forreceiving a purchase request from a user of the server system, whereinthe purchase request includes a product or service to be purchased. Theone or more programs further include instructions for determining avendor to supply the requested product based on the stored vendorprofiles. The one or more programs further include instructions forpurchasing the requested product from the determined vendor. The one ormore programs further include instructions for arranging for delivery ofthe purchased product or service.

In accordance with some implementations, a non-transitory computerreadable storage medium storing one or more programs configured forexecution by a server system is disclosed. The one or more programs alsoinclude instructions for storing one or more vendor profiles, whereineach vendor profile is associated with a particular vendor and includesone or more vendor category scores. The one or more programs furtherinclude instructions for receiving a purchase request from a user of theserver system, wherein the purchase request includes a product orservice to be purchased. The one or more programs further includeinstructions for determining a vendor to supply the requested productbased on the stored vendor profiles. The one or more programs furtherinclude instructions for purchasing the requested product from thedetermined vendor. The one or more programs further include instructionsfor arranging for delivery of the purchased product or service.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a client-server environment inaccordance with some implementations.

FIG. 2 is a block diagram illustrating a client system in accordancewith some implementations.

FIG. 3 is a block diagram illustrating a server system in accordancewith some implementations.

FIG. 4 depicts a block diagram of an exemplary data structure for a userprofile database for storing information related to users of the serversystem in accordance with some implementations.

FIG. 5 depicts a block diagram of an exemplary data structure for avendor profile database for storing information related to vendors ofthe server system in accordance with some implementations.

FIG. 6 is a flow diagram illustrating the process for selecting a vendorin accordance with some implementations.

FIG. 7 is a flow diagram illustrating the process for selecting a vendorin accordance with some implementations.

Like reference numerals refer to corresponding parts throughout thedrawings.

DESCRIPTION OF IMPLEMENTATIONS

In some implementations, a computer system operates a commerce systemfor allowing users to easily and quickly find and purchase goods andservices that meet their specific needs and desires. In someimplementations, the commerce system is available online via a web site,mobile electronic device, etc. In some implementations, the commercesystem operated by the computer system uses vendor profiles and userprofiles to select the most appropriate vendor to provide the product orservice requested by the user at the time of the transmission. Thecomputer system then purchases the desired product or service from theselected vendor and arranges for delivery of the product or service tothe user or another person indicated by the user (e.g., as a gift).

FIG. 1 is a block diagram illustrating a client-server environment 100in accordance with some implementations. The client-server environment100 includes one or more client systems 102-1 and 102-2, a server system120, and one or more vendors 170, all connected over a network 110. Insome implementations, the client system 102 includes one or more clientapplications 104 and a display 106. The server system 120 includes acommunication module 122, a request processing module 124, a vendorscoring module 126, a purchasing module 128, a vendor selection module130, a product database 140, a vendor database 150, and a user profiledatabase 160. The network 110 may consist of any one or more of any of avariety of networks, including local area networks (LAN), wide areanetworks (WAN), wireless networks, wired networks, the Internet, or anycombination of such networks.

In accordance with some implementations, the client system 102 includesone or more client applications 104. The one or more client applications104 include, but are not limited to, a web browsing application forconnecting to the server system 120. The client system 102 also includesa display 106. In some implementations, the client system is a computingdevice with the display integrated directly into the device itself, suchas a laptop, a smart phone, a personal computer, a tablet computer, orother computing device. In other implementations the display isconnected to, but not integrated into the client system. For example,desktop computer systems often do not have an integrated display andinstead connect to a standalone display.

In some implementations, the client system 102 transmits a purchaserequest 114 to a server system 120. In some implementations, thepurchase request 114 identifies a particular product or service that theuser requests the server system to purchase on his or her behalf. Insome implementations, the purchase request 114 includes a specificvendor associated with the product or service requested. In otherimplementations, the purchase request includes a vendor preferred by theuser, but which is able to be changed by the server system 120. In someimplementations, the purchase request 114 specifies a type or categoryof product, but not a specific product. In this implementation, theserver system 120 uses the included type or category information toselect a product or service as well as a vendor to satisfy the userpurchase request 114.

In some implementations, the purchase request 114 does not specify aparticular vendor, but includes a list of vendor attributes withassociated priority information. The list of vendor attributes with theassociated priority information is then used by the server system 120 toselect an appropriate vendor 170 to supply the requested product orservice. For example, if the purchase request 114 indicates that lowprice is the highest priority, the server system 120 then chooses thevendor that offers the lowest price on the requested product or service.In another example, if the purchase request 114 indicates that fastshipping is the highest priority, then the server system chooses thevendor that will deliver the product or service in the shortest amountof time (e.g., the product must be delivered in time for a specialoccasion, like Mother's Day).

In some implementations, the client system 102 sends a product addrequest 118 to the server system 120. In some implementations, theproduct add request 118 includes a product to be added to the productdatabase 140 of the server system 120. In some implementations, theproduct add request 118 specifies a product that is not already storedin the product database 140. In this implementation, the server systemadds the product included in the product add request 118 to the productdatabase 140. In other implementations, the product database 140 alreadyincludes the product specified in the product add request 118. In thisimplementation, the server system 120 updates the product database 140with information in the product add request 118. For example, if theproduct add request identifies a vendor for the product that the serversystem 120 did not have associated with the product, the server system120 edits the relevant product profile to include the new potentialvendor. In some implementations, the server system 120 verifies theinformation included in the product add request with a third party priorto editing the information stored in the product database.

In some implementations, the product add request 118 includesinformation describing the characteristics of the included product.Information describing the characteristics of a product includes, but isnot limited to: product specifications, price, size, color, one or morevendors that stock the item, time availability, and product stockamounts. In some implementations, the server system 120 adds a new entryin the product database 140 for the product included in the product addrequest 118 (e.g., when no entry for the product already exists). Inthis case, the information from the user describing the characteristicsof the product is used to fill out the new entry in the productsdatabase 140. Once the entry is added to the product database 140, theserver system 120 uses the newly added product to show and/or recommendto other users of the server system 120.

In some implementations, the product database 140 already includes theproduct described in the product add request. In this case, the serversystem 120 updates the product entry in the product database 140 toinclude any new information included in the product add request 118. Forexample, the product database 140 will be updated to include a newvendor associated with the product, to change the price of the productbased on the price included in the product add request 118, or to add anew product characteristic to the entry in the product database 140. Insome implementations, the product add request 118 is received as part ofa user recommendation and the product database is updated to include theuser who submitted the product add request 118 as a recommending user.In some implementations, the server system 120 verifies the informationincluded in the product add request 118 with a third party prior toadding or updating the new information to the product database.

In some implementations, the client system receives a vendorconfirmation request 116 from the server system 120. In someimplementations, the vendor confirmation request 116 lists a purchaserequest 114 the user has made and a vendor the server system 120 hasselected to complete the purchase, and requests that the user confirmthat the selected vendor 170 is acceptable to the user. In someimplementations, the user confirms the selected vendor 170 is acceptableto the user of the client system 102 and the client system 102 sends aconfirmation to the server system 120. In other implementations, theuser rejects the selected vendor 170 and a rejection is sent by theclient system 102 to the server system 120.

In some implementations, when the client system 102 sends a rejection ofthe selected vendor 170 to the server system 120, the rejection alsoincludes a vendor 170 selected by the user of the client system 102. Forexample, when the user rejects vendor A, the user also sends a requestfor vendor B. In other implementations, the rejection instructs theserver system 120 to select a different vendor. In some implementations,the rejection includes a list of vendor attributes that each have anassociated priority. The server system 120 then is able to select thevendor that most closely matches the priorities set out in therejection. For example, the rejection states that customer reviewratings above 4 stars are the highest priority and that price is thesecond highest priority. In this case, the server system 120 screens outthe vendors with average customer review rating below 4 stars and thenselects the vendor with the lowest price from among the remainingvendors. Thus, the selected vendor 170 will be the vendor with thelowest price among all the vendors 170 with customer service reviewscores that average above 4 stars.

In accordance with some implementations, the server system 120 includesa communication module 122, a request processing module 124, a vendorscoring module 126, a purchasing module 128, a vendor selection module130, a product database 140, a vendor database 150, and a user profiledatabase 160. The communication module is configured to send and receivecommunications over the network 110 to one or more client systems 102and one or more vendors 170.

In accordance with some implementations, the communication module 122handles all communication with the one or more client systems 102. Insome implementations, the communication module 122 receives a purchaserequest 114 from a client system 102. The communication module 122 sendsthe purchase request 114 to the request processing module 124. In someimplementations, the communication module 122 sends an acknowledgementback to the client system 102, indicating receipt of the purchaserequest 114. In some implementations, the communication module 122receives a product add request 118 from a client system 102. In someimplementations, the communication module 122 transmits the receivedproduct add request 118 to the product database 140 directly. In otherimplementations, the communication module transmits the received productadd request 118 to the request processing module 124.

In some implementations, the communication module 122 receives a vendorconfirmation request 116 from the vendor selection module 130. In someimplementations, the communication module 122 transmits the vendorconfirmation request 116 to the client system 102. In someimplementations, the communication module 122 is able to use one or moreof several different communication methods to transmit therecommendation 116 to the client system 102. The server system 120stores contact information for each user in the user profile database160.

In some implementations, the communication module 122 determines thecommunication method for communicating with a user based on pastcommunications with the user of the client system 102. Thus, thecommunication module 122 chooses the communication method that aparticular user of the client system 102 uses most often whencommunicating with the server system. For example, if a usercommunicates with the server system 120 through email in 75% ofcommunications, the server system 120 will use an email messaging systemto deliver a vendor confirmation request 116 to the user. In someimplementations, the communication module 122 uses a particular user'smost recent communication method to communication with that particularuser. In some implementations, each user selects one or more preferredcommunication methods and this preference is stored in the user profiledatabase 160. For example, a user selects text messaging as thepreferred method for receiving messages and in response thecommunication module 122 will then use text messages to send vendorconfirmation requests 116 to the user, unless directed otherwise. Insome implementations, the communication module 122 will use multiplecommunication methods to send vendor confirmation requests 116 to theuser.

In some implementations, the communication module 122 chooses thecommunication method based on the time and date that the vendorconfirmation request 116 is to be sent. For example, the communicationmodule 122 uses email messages to deliver vendor confirmation requests116 during the standard workday (9 am-5 pm Monday through Friday) anduses text messages to deliver vendor confirmation requests 116 duringevening and on weekends. In some implementations, no vendor confirmationrequests 116 will be sent during typical sleeping hours. In someimplementations, each user selects time and data preferences for thecommunication module 122 to use and these preferences are stored in theuser profile database 150. The communication module then follows theuser selected preferences when communicating with the client system 102associated with the user.

In some implementations, the communication module 122 receives aresponse message from a client device either confirming the selectedvendor or rejecting the selected vendor. In either case, the responsemessage is transmitted to the vendor selection module 130. In someimplementations, the communication module 122 sends a vendorconfirmation request 116 that includes alternative vendors to the vendorselected by the server system 120. In this case, the response messagereceived from the client system 102 included user's selection of one ofthe alternative vendors. If so, the server system 120 uses the selectedalternative vendor. In some implementations, the response message fromthe client system 102 also confirms or rejects other aspects of thepurchase request 114. For example, the user rejects or accepts theshipping terms, the specific product SKU selected, or the shippingaddress.

In accordance with some implementations, the request processing module124 is configured to receive requests from a plurality of client systems102 via the communication module 122. In some implementations, theclient system 102 receives a purchase request 114 from a client system102. In some implementations, the request processing module 124determines whether the requested product is stored in the productdatabase 140. If the requested product is already stored in the productdatabase, the request processing module 124 requests the user profile ofthe user associated with the purchase request from the user profiledatabase 160. Once the user profile is received by the requestprocessing module, the request processing module 124 transmits thepurchase request 114 and the retrieved user profile to the vendorselection module 130.

In some implementations, the product requested in the purchase request114 is not already stored in the product database 140. In this case, therequest processing module 124 determines whether the purchase request114 also includes a product add request 118. In some implementations,the purchase request 114 includes a product add request 118 and therequest processing module 124 transmits the data necessary to create aproduct entry in the product database 140 to the product database 140.In other implementations, the purchase request 114 does not include aproduct add request 118. In this case, the request processing module 124requests information for the requested product from a plurality ofvendors 170 through the network 110. In some implementations, theproduct database 140 requests at least the basic information necessaryto recommend the product a user (e.g., name of the produce, price,shipping terms and price, and at least a basic description of the itemsattributes.) By contacting various vendors 170 or other third partysites (e.g., catalog aggregation sites or product information databasesites) for product information, the request processing module 124 isable to fill out a product entry for the new product in the productdatabase 140 and gather a list of vendors that stock the product.

In some implementations, the request processing module 124 receives aproduct add request 118 from a client system 102. In someimplementations, in response to receiving a product add request 118, therequest processing module 124 determines, for each respective product ofthe one or more products included in the product add request 118,whether the respective product included in the product add request 118is already included in the product database 140. If the respectiveproduct is included in the product database, the request processingmodule 124 determines whether any of the information included in theproduct add request 118 differs from the corresponding product entry inthe product database 140. The request processing module 124 updates theinformation stored in the product database 140 to include anydifferences. For example, if the product price for a product in theproduct add request 118 is lower than the price indicated in the productentry in the product database 140, the product database 140 is updatedto reflect the lower price. In some implementations, each productincluded in a product add request 118 has an associated vendor 170.Correspondingly, each product entry in the product database includes alist of vendors that stock the product. In response to receiving aproduct add request 118, the product entry for each product included inthe product add request 118 is updated to include a vendor associatedwith the product in the product add request 118 in the list of vendors.

In some implementations, the request processing module 124 transmits thereceived purchase request 114 to a vendor selection module 130 todetermine the optimal vendor to supply the requested product or service.In some implementations, the vendor selection module 130 determines alist of all potential vendors 170 that are able to supply the requestedproduct or service to the user. In some implementations, the vendorselection module 130 sends the list of potential vendors to the vendorscoring module 126 for scoring.

In some implementations, the purchase request 114 includes a list ofvendor category priorities (e.g., to be used to weight the variousvendor category scores). In this implementation, the vendor scoringmodule 126 sends the set of vendor category priorities to the vendorscoring module 126.

In some implementations, the vendor scoring module 126 generates scoresfor one or more vendors 170. In some implementations, the vendor scoringmodule 126 collects data about vendors. In some implementations, thisdata is gathered from the vendors 170 themselves. For example, thevendor scoring module 126 requests the location of the vendor, thecountry of origin, the prices of the products supplied by the vendor170, shipping policies, shipping options and prices, inventory status,and return policies from the vendors directly. In some implementations,the vendor scoring module 126 gathers data from users. For example,users can submit feedback to the server system 120 rating the customerservice quality, the shipping speed, and the return policies of thevendor 170.

In some implementations, vendor scoring module 126 uses the gatheredinformation to generate a plurality of vendor category scores. Eachrespective vendor category score is associated with a particularattribute of a respective vendor 170. In some implementations, eachvendor category score is a number that rates a particular attribute of avendor on a numerical scale. For example, a particular vendor categoryis customer service quality and each vendor category score is a numberbetween 1 and 10, with 1 being the worst and 10 being the best. In someimplementations, the purchase request 114 includes a set of prioritiesfrom the user that are used to weight the various vendor category scoresand determine an overall vendor score for each vendor. In someimplementations, the purchase request 114 does not include a set ofpriorities. In this case, the vendor scoring module 126 uses apredefined set of default priorities. In some implementations, theserver system 120 defaults to weighing each vendor attribute or categoryequally. In some implementations, the server system 120 defaults toprioritizing price as the highest priority category or factor.

In some implementations, the vendor scoring module 126 accesses the userprofile database 160 to determine the set of category priorities for theuser that submitted the purchase request 114. In this case thepriorities are based on, among other priorities, past user purchaserequests, the user's budget, the user's location, the priorities ofusers that have been trusted by the user, and other relevant informationstored in the user profile.

In some implementations, the vendor scoring module 126 receives arequest from the vendor selection module 130 to generate overall vendorscores for a plurality of vendors 170. In some implementations, thevendor scoring module 126 receives priorities associated with the one ormore vendor categories from the vendor selection module 130. In someimplementations, the vendor scoring module 126 generates overall vendorscores by using the received category priorities to weight the vendorcategory scores. For example, vendor profile 152 has three categoryscores: shipping time, price, and customer service. Vendor A has a scoreof 8 for shipping time, a score of 3 for price, and a score of 10 forcustomer service. User A has priorities set such that customer serviceis twice as important as price, and shipping time as not important atall. Thus, weighing the score would be (shipping score*shipping scoreweight+price score*price score weight+customer service score*customerservice weight)/total number of factors and would result in(0*8+1*3+2*10)/3=7.66.

In some implementations, once the overall vendor scores have beencalculated for the plurality of vendors, the vendor scoring module 126sorts the plurality of vendors into a list that is sorted from highestoverall score to lowest overall score. Once the vendor scoring module126 sorts the plurality of vendors into a list, the vendor scoringmodule 126 sends the sorted list to the vendor selection module 130. Insome implementations, the vendor scoring module 126 also sendscalculated scores to the vendor selection module 130.

In some implementations, the vendor selection module 130 receives asorted list of vendors from the vendor scoring module 126. In someimplementations, the vendor selection module 130 selects the vendor thatmost closely matches the user's needs. In some implementations, the userhas specified a vendor 170. In some implementations, the vendorselection module 130 always uses the user specified vendor when a vendorhas been specified by the user. In some implementations, the user hasindicated that only the specified vendor may be considered by the serversystem 120. In other implementations, the user has indicated that serversystem 120 can consider alternatives to the specified vendor and thevendor selection module 130 compares the overall score of the vendorspecified by the user and the vendor with the best overall vendor scoreper the ranked list of vendors provided by the vendor scoring module126. If the vendor specified by the user has an overall score that islower than the top scored vendor by at least a predetermined score, thevendor selection module 130 will select the top scoring vendor insteadof the vendor specified by the user. For example, the user has indicateda preference for vendor A, and vendor A receives an overall score of 5.5(out of ten) and vendor B receives an 8.6, which is the highest scorefrom the vendor scoring module 126. The difference is 3.1. If the vendorselection module 130 has a predetermined maximum difference value of 2,the vendor selection module 130 will select vendor B, despite the user'sindicated preference. In some implementations, the maximum differencevalue will vary depending on the strength of the preference that theuser has for the indicated vendor. If the user has indicated a verystrong preference, a larger difference in score will be necessary tojustify switching to a new vendor. If the user has only a weakpreference, a small difference in score will be sufficient to justify aswitch. In some implementations, the user preference will be so stronglypreferred that the vendor selection module 130 will not change vendorsregardless of other vendor scores.

In some implementations, if the vendor selection module 130 selects avendor that is different from the user specified vendor, the vendorselection module 130 sends a vendor confirmation request 116 to theclient system 102. The vendor confirmation request 116 will identify theselected vendor, provide an explanation why the vendor was selected(e.g., this vendor provides a lower price, with the same shipping time),and requests that the user of the client system 102 confirm the choiceof new vendor. In some cases, the client system 102 responds andconfirms the vendor choice. In other cases, the client system 102responds and specifies that the user has rejected the selected vendor.In this case, the vendor selection module 130 will select anothervendor. In some implementations, the vendor selection module 130 revertsto the user specified vendor.

In some implementations, the user has not specified a preference for aparticular vendor, but the vendor selection module 130 determines one ormore vendors favored by the user based on the user's past purchasinghistory. If a user has given positive feedback for a vendor in the past,the vendor selection module 130 will give that vendor an advantage infuture consideration. For example, if Vendor A and Vendor B both score a7.5 overall vendor score for a particular purchase request 114, and theuser associated with the purchase request 114 has previously givenVendor B a positive review, the vendor selection module 130 will modifythe overall score by a specific amount to reflect this positiveexperience. The exact amount of benefit given to the vendor will dependon the number of times the user has given positive feedback for a vendorand how positive the feedback was. Thus, as a user consistently givespositive feedback to a specific vendor over time, the amount that thevendor scoring module 126 adjusts the specific vendors overall scoreincreases. Similarly, in some implementations, the vendor selectionmodule 130 will determine that a user has given poor feedback to aspecific vendor. In this case, the vendor selection module 130 willadjust the vendors overall score down in response. The amount that thevendors overall score is adjusted up or down varies based on the numberof positive or negative reviews received from the user and the degree towhich the review is positive or negative.

In some implementations, the vendor selection module 130 determines userfavored vendors based on the vendors having been recommended andreviewed positively by other users of the server system 120 in which thepurchasing user has indicated trust. Thus, vendors recommended orreviewed positively by other trusted users will have their overallscores modified up and vendors reviewed negatively will have theiroverall scores modified down. In some implementations, the amount ofmodification depends on the level of trust between the two users. Forexample, User A has indicated a high level of trust in User B and User Bhas highly reviewed Vendor C. When the vendor selection module 130 isselecting a vendor for a user A purchase request 114, the overall scoreof Vendor C is modified up.

In some implementations, when the server system 120 receives userfeedback, the communication module 122 updates the vendor database 140to reflect the feedback. In this way, vendor scores can be adjusted upor down based on the received user feedback.

In some implementations, the vendor selection module 130 will select twoor more potential vendors and transmit a vendor selection message to theclient system 102. The user can then select a vendor from the potentialvendor choices. In some implementations, the vendor selection module 130sends the user indicated vendor and the highest scoring vendor. In someimplementations, the vendor selection module 130 also transmits anexplanation of why each vendor is offered as an option. In someimplementations, the explanation is displayed in response to the userinput having requested one or more explanations. For example, the vendorselection module 130 transmits a vendor selection message to the clientsystem 102 Vendor A and Vendor B, noting that Vendor A has a lower pricebut with slower shipping and that Vendor B has a more expensive pricebut with faster shipping. In some implementations, the vendor selectionmessage includes the specific spice and supply times to help the usermake the best decision.

In some implementations, the purchasing module 128 is configured toreceive a purchase request from the vendor selection module 130. Thepurchase request includes a product to be purchased and a vendor to beused. In some implementations, the purchasing module 128 then enliststhe communication module 122 to purchase the desired product from thedetermined vendor 170 available over the network 110. In someimplementations, the purchasing module 128 arranges for delivery of theproduct or service according to the instructions from the user of theclient system 102. In some implementations, purchases from vendors aremade through an application programming interface (API). In otherimplementations, purchases are made manually by workers associated withthe server system either in person, on the phone, or electronically(e.g., an employee calls a vineyard to place an order for wine that wasorder through the server system). In some implementations, thepurchasing module 128 allows vendors to make bids on products. In thisway, once a user has issued a buy product request, the purchase module128 can notify one or more vendors, receive the vendors bids, and choosethe vendor that offers the best value. In this way, vendors can have apublicly listed price, but then can bid at a lower price in certainsituations without publicly publishing the lower price.

In some implementations, the purchasing module 128 purchases therequested products from users of the server system 120. In this way,users of the server system 120 can both buy and sell products throughthe service. In this way, the server system is able to find the bestvalue for users of the server system 120. In some implementations, thepurchasing module 128 negotiates with the rights holders and organizingthe product of a particular good or service. In some implementations,the purchasing module 128 is able to take orders for products andservices that are created on demand or would normally not be availablefrom a traditional commerce system.

In some implementations, the purchase request from a user includes ablend of “product” and “service” from various or multiple vendors. Forexample, the server system could coordinate the delivery of a swing setfrom a seller on Craigslist, and have a service provider to deliver it,sand it, re-stain it and install it. In this case, the purchase module128 would negotiate or order from each vendor and then arrange forco-ordination between the various providers to ensure that the productand services are delivered promptly and at a low cost. In this was usershave a single point of contact (the server system) to get a good priceon a complicated set of services and goods. This has the benefit ofreducing price and difficulty.

In some implementations, the product or service requested is deliveredrepeatedly (e.g., a bacon of the month club) or contracted over a longtime (e.g., a 2 year cell phone plan). In this case the purchase module128 arranges for both payment and delivery on a regular schedule toprovide convenience to both the vendor and the user.

In some implementations, the purchase module 128 can use coupons,discounts, and other means of adding marketplace value to a transactionon behalf of the user, even when the user is unaware of the couponsprior to placing a purchase order.

In some implementations, the product database 140 contains a pluralityof product entries. Each product entry is associated with a singleproduct and contains information related thereto. In someimplementations, the product entries store the unique identifier of theproduct (e.g., bar code, name and module number, SKU number, or otherproduct identifier), the specifications of the product (size, color,capacity, etc), a list of vendors that can supply the product, the priceof the product, and any other pertinent information. In someimplementations, different vendors will have different prices and thusthe product entry in the product database 140 will store a list ofvendors and a vendor specific price for each vendor. For example, if aproduct is available from 4 vendors, the product database 140 will storea separate price for each vendor.

In some implementations, the products in the product database 140 areadded by partner vendors 150. In some implementations, the products inthe database 140 are added by users and recommenders in the serversystem 120. In other implementations, the product database 140 is filledby crawlers using algorithms specified by the server system 120. In yetother implementations, the product database 140 is filled through acombination of crowd sourcing (e.g., users can submit products andassociated information) and paid human labor (e.g. services whereworkers are paid a small fee to add new products to the database.) Theproducts database 140 includes information for each product, including,but not limited to, the price of the product, its specification (size,color, etc), the vendor or vendors from which it is available, whetherthe item is in stock, and whether it is available for delivery. In someimplementations, the vendor selection module 130 and the purchasingmodule 128 use the information stored in the product database 140 topurchase the selected product. In some implementations, the productdatabase 140 searches websites of vendors, or other databases maintainedby vendors that are available over a network 110, for the desiredproduct and updates the product database 140 based on information storedon websites or in catalogs. In some implementations, the information inthe product database includes a time stamp or other date indication.Thus, if a product is on sale or otherwise time limited, the productdatabase can notify users or make recommendations at the appropriatetime.

In some implementations, the vendor database 150 includes a database ofall the vendors associated with the server system 120. In someimplementations, the vendor database includes vendor profiles 152. Insome implementations, a vendor profile 152 includes the name of thevendor, vendor location, vendor nationality, one or more vendor categoryscores, user feedback for the vendor, and any other relevantinformation. In some implementations, a vendor profile 152 includescontact information submitted by the vendor or stored by the systemafter contact with the vendor including but not limited to websites,email addresses, phone numbers, user names, instant message user IDs,and social networking sites sufficient to allow the service to contactthe vendor or an agent of the vendor. In some implementations, thecommunication module 122 uses information stored in the vendor database150 to send communications to the vendor.

In some implementations, the user profile database 160 contains userprofiles for users who have registered to use the service provided bythe server system 120. In some implementations, a user profile includesthe name, ID, demographic information (gender, age, location, etc),purchasing history, social network information, and trust information.The user profile database 160 includes trust graph data. In someimplementations, the trust graph data includes information describing adirected trust graph. The trust graph includes nodes, which representusers, and edges connecting nodes, which represent the trust levelbetween the two users represented by the two nodes that the edgeconnects.

The user profile database 160 includes trust graph data. In someimplementations, the trust graph database includes informationdescribing a directed trust graph. The trust graph includes nodes, whichrepresent users, and edges connecting nodes, which represent the trustlevel between the two users represented by the two nodes that the edgeconnects.

In some implementations, the vendors 170 are commercial organizationswith products to sell. The vendors 170 can receive orders to purchaseproducts from the server system 120 and fulfill those orders.

FIG. 2 is a block diagram illustrating a client system 102, inaccordance with some implementations. The client system 102 typicallyincludes one or more processing units (CPUs) 202, one or more networkinterfaces 210, memory 212, and one or more communication buses 214 forinterconnecting these components. The client system 102 includes a userinterface 204. The user interface 204 includes an associated displaydevice 104 and optionally includes an input means such as a keyboard,mouse, a touch sensitive display, or other input buttons 208.Optionally, the display device 106 includes an audio device or otherinformation delivery device. Furthermore, some client systems use amicrophone and voice recognition to supplement or replace the keyboard.

Memory 212 includes high-speed random access memory, such as DRAM, SRAM,DDR RAM or other random access solid state memory devices; and mayinclude non-volatile memory, such as one or more magnetic disk storagedevices, optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices. Memory 212 may optionallyinclude one or more storage devices remotely located from the CPU(s)202. Memory 212, or alternately the non-volatile memory device(s) withinmemory 212, includes a non-transitory computer readable storage medium.In some implementations, memory 212 or the computer readable storagemedium of memory 212 stores the following programs, modules and datastructures, or a subset thereof:

-   -   an operating system 216 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 218 that is used for connecting        the client system 102 to other computers via the one or more        communication network interfaces 210 (wired or wireless) and one        or more communication networks, such as the Internet, other wide        area networks, local area networks, metropolitan area networks,        and so on;    -   a display module 220 for enabling display of media content on a        display 106 associated with the client system 102;    -   one or more client system 102 applications module(s) 104 for        enabling the client system 102 to perform the functions offered        by the client system 102, including but not limited to:        -   a browser application 224 for sending purchase requests 114            to a server system (FIG. 1, 120) and displaying the            information (for example web pages) returned by the server            system (FIG. 1, 120) or a smart phone or other computer            system application that performs the same function;        -   a product request module 226 for enabling a user to send a            product request 114 to a server system (FIG. 1, 120) and            receiving a vendor confirmation request 116 from the server            system to confirm the vendor selected by the server system            120;        -   a product add request module 228 for enabling a user to send            a product add request 118 to a server system 120 to add a            product to the product database 140; and/or    -   one or more client data module(s) 230 for storing data related        to the client system 102, including but not limited to:        -   client message data 232, including data representing            messages to be sent to the server system (FIG. 1, 120) and            messages received from the server system (FIG. 1, 120);            and/or        -   user profile data 234, including information concerning            users of the client system 102 such as a user profile, user            preferences and interests, user contact information, and            other information relevant to providing services to the            user.

FIG. 3 is a block diagram illustrating a server system 120 in accordancewith some implementations. The server system 120 typically includes oneor more processing units (CPUs) 302, one or more network interfaces 304,memory 306, and one or more communication buses 308 for interconnectingthese components.

Memory 306 includes high-speed random access memory, such as DRAM, SRAM,DDR RAM or other random access solid state memory devices; and mayinclude non-volatile memory, such as one or more magnetic disk storagedevices, optical disk storage devices, flash memory devices, or othernon-volatile solid state storage devices. Memory 306 may optionallyinclude one or more storage devices remotely located from the CPU(s)302. Memory 306, or alternately the non-volatile memory device(s) withinmemory 306, includes a non-transitory computer readable storage medium.In some implementations, memory 306 or the computer readable storagemedium of memory 306 stores the following programs, modules and datastructures, or a subset thereof:

-   -   an operating system 310 that includes procedures for handling        various basic system services and for performing hardware        dependent tasks;    -   a network communication module 122 that is used for connecting        the server system 120 to other computers via the one or more        communication network interfaces 304 (wired or wireless) and one        or more communication networks, such as the Internet, other wide        area networks, local area networks, metropolitan area networks,        and so on;    -   one or more server application module(s) 314 for enabling the        server system 120 to perform the functions offered by the server        system 120, including but not limited to:        -   a request processing module 124 for receiving purchase            requests (FIG. 1, 114) and product add requests (FIG. 1,            118) from a client system (FIG. 1, 102) and processing the            requests before passing relevant data to the vendor            selection module 130 and the vendor scoring module 126;        -   a vendor scoring module 126 for generating overall category            scores for vendors based on a variety of criteria,            generating overall scores for vendors based on the criteria            scores and priority information supplied by the user or the            server system 102, and ranking vendors based on their            overall scores;        -   a purchasing module 128 for purchasing a product or service            from one of the vendors (FIG. 1, 170);        -   a vendor selection module 130 for identifying vendors (FIG.            1, 170) that offer a product or service received from the            request processing module 124, transmitting the identified            vendors to the vendor scoring module 126 to score the list            of identified vendors, and selecting a vendor based on user            preferences and overall vendor scores; and/or    -   one or more server data module(s) 330 for storing data related        to the server system 120, including but not limited to:        -   user profile data 150 including user preferences and            interests, user contact information, and user history,            including past user purchases, searches, page views,            previous product recommendations, previous product reviews,            social connections of the user, preferred vendors, vendor            reviews, and any other information related to the user;        -   vendor data 150 including a database of all the vendors            associated with the server system 120 and the vendor            profiles data 152 for each vendor;        -   product data 140 including information for products that may            be purchased through the server system 120, including, but            not limited to, the price of the product, its features            (size, color, etc), recent changes in price, and the vendor            or vendors from which it is available; and/or        -   vendor profile data 152 including the name of the vendor,            vendor location, vendor nationality, one or more vendor            category scores, user feedback for the vendor, and any other            relevant information.

FIG. 4 depicts a block diagram of an exemplary data structure for a userprofile database 160 for storing information related to users of theserver system (FIG. 1, 120). In accordance with some implementations,the user profile database 160 includes a plurality of user profiles402-1 to 402-P, each of which corresponds to a user registered with theserver system (FIG. 1, 120). In some implementations, each user profile402 contains a user profile ID 404, a user history 406, trustinformation 408, recommendations 410 made by the user, user contactinformation 412, and vendor preferences 414.

In some implementations, user profile ID 404 is a value that uniquelyidentifies a specific user of the server system (FIG. 1, 120). In someimplementations, this value is chosen by the user and is a user name. Inother implementations, this value is assigned to the user by the serversystem (FIG. 1, 120) as part of the registration process.

In some implementations, the user history 406 stores a history of theuser's past interactions with the server system (FIG. 1, 120) includingpast user purchases and purchase details, searches, page views, previousproduct recommendations, previous product reviews, and socialconnections of the user including previously recorded trust informationfor other users and/or social information received from socialnetworking sites.

In some implementations, trust information 408 includes data describingthe social connections of the user and includes a trust level for otherusers of the server system (FIG. 1, 120). A trust level is a valuerepresenting the degree to which a user trusts the opinions andrecommendations of another user. In some implementations, trustinformation is explicitly submitted by the users, in other situationsthe server system (FIG. 1, 120) infers trust information from theactions of users, and in yet other situations trust information includesinformation from both user submissions and server inferences.

In some implementations, recommendation 410 data includes productpurchases and product recommendations previously submitted by the user.In some implementations, contact information 412 includes a list ofcontact information for contacting the user through a plurality ofcommunication methods and information describing if and when the serversystem (FIG. 1, 120) should use that method. For example, the contactinformation 412 includes but is limited to, email addresses, phonenumber, Twitter handle, social network ID, physical address and anyother information that helps the server system (FIG. 1, 120) contact theuser. The user may select that the server system (FIG. 1, 120) shouldnever use social network messaging to contact to user and should useemail address at all times except for the weekend and that a textmessage to a mobile phone should be used on the weekend. In someimplementations, the contact information 412 includes login and passwordinformation for one or more social networking sites.

In some implementations, vendor preference data 414 includes dataindicating the user's vendor preferences. In some implementations,vendor preference data 414 includes vendors that the user has explicitlyindicated as preferred vendors and vendors that the user has explicitlyindicated as non-preferred vendors. In some implementations, vendorpreference data 414 is determined based on previous user behavior (e.g.,vendors that the user has repeatedly selected). In some implementations,a user's vendor preference is based on feedback or reviews from theuser. Vendors that received positive reviews will be noted as potentialfavored vendors and vendors that receive negative reviews will be notedas potential disfavored vendor.

In some implementations, contact information stored for the userincludes one or more ways to contact the user including, but not limitedto, email addresses, phone number, Twitter handle, social network ID,physical address and any other information that helps the server system(FIG. 1, 120) contact the user.

FIG. 5 depicts a block diagram of an exemplary data structure for avendor database 150 for storing information related to vendorsassociated with the server system (FIG. 1, 120). In accordance with someimplementations, the vendor database 150 includes a plurality of vendorprofiles 152-1 to 152-P, each of which corresponds to a vendorassociated with or accessible by the server system (FIG. 1, 120) (e.g.,vendors from whom the server system can purchase products or services).In some implementations, each vendor profile 152 contains a vendorprofile ID 504, a vendor name 506, vendor location data 508, userfeedback data 510, vendor category scores 512, and contact information514 for the vendor.

In some implementations, vendor profile ID 504 is a value that uniquelyidentifies a specific vendor associated with or accessible to the serversystem (FIG. 1, 120). In some implementations, this value is chosen bythe vendor. In other implementations, this value is assigned to thevendor by the server system (FIG. 1, 120).

In some implementations, the vendor name 506 is a string that identifiesthe vendor to users of the server system (FIG. 1, 120). In someimplementations, the vendor name is a name associated with the vendorthat is well known to users. For example, if a brand name is morecommonly known to users than the official corporate or legal name of thevendor, the brand name could be included as the vendor name 506.

In some implementations, vendor location 508 includes data describingthe location of the vendor, including country of origin and the locationof its headquarters and any distribution points. In someimplementations, the vendor location 508 also includes estimatedshipping times. In some implementations, the product information 510includes data describing the products available from the vendor. In someimplementations, product information 510 also includes prices, inventorystatus, delivery options, product customization options, and any otherinformation related to the products offered by the vendor.

In some implementations, category score profiles 512 include a pluralityof scores for a plurality of categories associated with the vendor. Forexample, relevant vendor category scores include separate scores forshipping time, user experience, average price, return policy, and anyother categories that might be useful. In some implementations, thecategories are predetermined by the server system.

In some implementations, each category score profile 512 includes acategory number 520 that identifies the category. In someimplementations, the category number 520 is an integer that identifiesthe same category in all vendor profiles 152. For example, the “averageprice” category is assigned the category number 21, the server systemknows that every vendor category score with the category number 21 isaverage price. In some implementations, the category data 522 is textthat identifies the type of category score. For example, category datawould include a text description such as “user experience” or “returnpolicy.”

In some implementations, each category score profile 512 includes acategory score 524. In some implementations, a category score is anumber within a range that represents how well the vendor performs onthe metric measured by the category. In some implementations, all thecategory scores use the same scale. In other implementations, eachcategory score profile 512 has a customized scale. For example, allcategory scores are a number between 0 and 10 with 0 being the lowestscore and 10 being the highest. Each vendor is evaluated in one or morecategories and is assigned a category score for each category. In someimplementations, category scores 524 are updated as new information isreceived by the server system (FIG. 1, 120). In some implementations,new information is received in the form of user submitted feedback andreviews. In other implementations, new information is received from thevendors themselves (e.g., new price information or new shippinginformation).

In some implementations, each category score profile 512 includes adefault weight 526. In some implementations, the default weight is theweight given to the category score when no specific weight for thecategory has been indicated by a user. For example, the default categoryweight for the category “average price” is high, while the defaultcategory weight for the category “return policy” is lower. In someimplementations, the category score profile includes user feedback 528received from user relevant to the category associated with the categoryscore profile 512.

FIG. 6 is a flow diagram illustrating the process for click-lesspurchasing in accordance with some implementations. Each of theoperations shown in FIG. 6 may correspond to instructions stored in acomputer memory or computer readable storage medium. Optional operationsare indicated by dashed lines (e.g., boxes with dashed-line borders). Insome implementations, the method described in FIG. 6 is performed by theserver system (FIG. 1, 120).

In some implementations, the server system (FIG. 1, 120) creates (602)one or more vendor profiles. In some implementations, vendor profilesstore information related to a vendor accessible to the server system(FIG. 1, 120). Stored information includes, but is not limited to, thename of the vendor, products offered by the vendor, price informationfor the products offered by the vendor, product ordering procedures forthe vendor, vendor location, and shipping times and procedures. In someimplementations, the vendor profiles store any information necessary forpurchasing products or services from the vendor.

In some implementations, the vendor profiles include scores for thevendor for one or more attribute categories. In some implementations,creating vendor profiles includes determining (604) one or more vendorscoring categories. In some implementations, vendor scoring categoriesinclude average price, delivery time, and user satisfaction. In someimplementations, the server system (FIG. 1, 120) then, for one or moredetermined vendor scoring categories, generates (606) a vendor categoryscore based on past vendor performance. In some implementations, avendor category score is an indication of how well the vendor performsin that category. For example, if the category was return policies,vendors with good return policies would receive high scores and vendorswith poor return policies would receive low scores.

In some implementations, past vendor performance is based on usersupplied feedback (608). In some implementations, user supplied feedbackincludes user reviews, user ratings, and user submitted recommendations.For example, a user submits ratings for a vendor based on a recentpurchase and gives the vendor 5 stars out of 5 for shipping time and 4out of 5 stars for customer service. The user ratings are then used toadjust the corresponding category scores.

In some implementations, past vendor performance is determined based ondata directly measured by the server system (FIG. 1, 120) (610). Forexample, the server system (FIG. 1, 120) tracks prices for productsoffered by a vendor at regular intervals and compares those pricesagainst prices offered for the same products at other vendors during thesame intervals. Based on the tracked prices, the server system (FIG. 1,120) can generate a price average category score for each vendor. Thus,if the server system (FIG. 1, 120) periodically checks the current pricefor a specific product with a plurality of vendors, it can determine anaverage price. Based on the average price, the server system (FIG. 1,120) can rate each vendor as below or above the average price and bycollecting ratings for a plurality of products, the server system giveseach vendor an average price score. In some implementations, the datameasured by the computer system includes product delivery time, productprice, and number of products in stock.

In some implementations, the server system (FIG. 1, 120) stores (614)one or more vendor profiles, wherein each vendor profile is associatedwith a particular vendor and includes one or more vendor category scores(612). Each category score is associated with a particular attribute ofa vendor. In some implementations, the server system (FIG. 1, 120)receives (616) a purchase request from a user of the server system,wherein the purchase request includes a product or service to bepurchased. For example, the purchase request includes a request for acopy of season 2 of “Breaking Bad” on DVD. In some implementations, therequest also includes a user preferred vendor for fulfilling therequest. In some implementations, the purchase request does not includea preferred vendor, and the server system (FIG. 1, 120) accesses theproduct database to determine a list of vendors that sell the requestedproduct. In some implementations, the product database includes apreferred vendor for the requested product.

In some implementations, the server system (FIG. 1, 120) determines(618) a vendor to supply the requested product based on the storedvendor profiles. In some implementations, the server system (FIG. 1,120) selects the vendor included in the purchase request. In someimplementations, the server system (FIG. 1, 120) selects a vendor fromamong a list of preferred vendors stored in the user profile of the userwho submitted the request. In some implementations, the server system(FIG. 1, 120) selects a vendor by determining vendors preferred by usersof the server system (FIG. 1, 120) that are trusted by the requestinguser.

In some implementations, when the server system (FIG. 1, 120) determines(620) a vendor to supply the requested product based on the storedvendor profiles, the server system (FIG. 1, 120) further, for eachvendor in the plurality of vendors: generates a overall vendor scorebased on the one or more vendor category scores wherein the one or morevendor category scores are weighted based on the priority associatedwith each category. In some implementations, the weights are based oncategory priorities received from the user. In some implementations, theserver system (FIG. 1, 120) has default category weights that are usedwhen no priorities are received from the user or stored in the user'sprofile.

In some implementations, the server system (FIG. 1, 120) ranks (622) theplurality of vendors based on the generated overall vendor score. Thusthe list includes a list of vendors ordered from highest overall vendorscore (e.g., best vendor match) to lowest overall vendor score (e.g.,worst vendor match). In some implementations, the priorities associatedwith the one or more vendor categories are predetermined by the computersystem.

FIG. 7 is a flow diagram illustrating the process for click-lesspurchasing in accordance with some implementations. Each of theoperations shown in FIG. 7 may correspond to instructions stored in acomputer memory or computer readable storage medium. Optional operationsare indicated by dashed lines (e.g., boxes with dashed-line borders). Insome implementations, the method described in FIG. 7 is performed by theserver system (FIG. 1, 120).

In some implementations, the server system (FIG. 1, 120) stores (702)user profiles for each user of the computer system; wherein userprofiles include priorities associated with vendor categories. In someimplementations, the server system (FIG. 1, 120), prior to purchasingthe requested product, sends (704) a request to the user to confirm thedetermined vendor. In some implementations, the server system (FIG. 1,120) receives 706 a response from the user confirming the determinedvendor. In some implementations, the response authorizes the use of thedetermined vendor. In other implementations, the response from the userincludes a rejection of the determined vendor.

In some implementations, the server system (FIG. 1, 120) purchases (708)the requested product from the determined vendor. In someimplementations, the server system (FIG. 1, 120) only purchases therequest product in response to a response from the user that authorizesthe use of the determined vendor. In some implementations, the serversystem (FIG. 1, 120) arranges (710) for delivery of the purchasedproduct or service.

In some implementations, the server system (FIG. 1, 120) receives (712)feedback from the user regarding the determined vendor. In someimplementations, the server system (FIG. 1, 120) updates (714) thevendor profiles based on the received feedback. In some implementations,the server system (FIG. 1, 120) includes a product database (716). Insome implementations, the server system (FIG. 1, 120) receives (718) arequest to add a product to the product database, wherein the requestincludes a vendor associated with the product. In some implementations,the request to add a product to the product database is a recommendationfrom a user. In some implementations, the request to add a product tothe product database is included in the purchase request.

Trust Graph

In some implementations, a server system for improving the reliabilityof an Internet based commerce service through social network basedproduct recommendations using a trust graph. A trust graph representstrust between users. The server system maintains a record of the trustrelationships for each user registered with the service provided by theserver system. In some implementations, the server system then uses thisinformation to identify the most trusted users in at least one area of aparticular user's trust graph.

In some implementations the server system receives a trust indicationfrom a first user. The trust indication includes information identifyinga second user of the plurality of users registered with the serversystem and a trust level that represents the level of trust that thefirst user has for the second user. In some implementations the trustgraph is a directed graph, such that a particular trust indication onlyindicates the level of trust that the first user has for the second userand not the level of trust between the second user and the first user.As the first user sends more trust indications to the server, thedirected trust graph of the first user includes trust information andbecomes more useful. For example, a first user Bob sends three trustindications to the server system, indicating Joe, Phil, and Deborahrespectively, each with a high trust level. The server system will thenstore these trust indications in a directed trust graph for Bob. Becausethe trust graph is directed, the server system does not infer trustlevels for Joe, Phil, and Deborah toward Bob based on Bob's trust leveltowards them.

In some implementations, trust level is represented by a numerical valuebetween 0 and 1, with 0 indicating no trust and 1 indicating maximumtrust. in other implementations, the trust level is represented by anumerical value between −1 and 1, wherein 1 indicates maximum trust, −1indicates maximum distrust, and 0 indicates no current trustinformation. For example, if Jim totally trusts his friend Pam, he wouldindicate a trust level of 1. For Jim's friend Andy, who he trusts, butnot as much as Pam, Jim would indicate a trust level score between 0 and1, such as 0.5. Further, for a distrusted person, such as Dwight, Jimwould indicate a score below 0 but above −1, such as −0.5.

In accordance with some implementations, the server system can infertrust information by identifying actions taken by a particular user anddetermining the trust level indicated by the identified actions. Forexample, if the server system determines that Jim has received arecommendation for a pair of shoes from Andy, the server system canmeasure Jim's response to determine a trust level between Andy and Jim.If Jim purchases the recommended pair of shoes, the system willdetermine an increased level of trust from Jim to Andy. If Jim takes noaction based on the recommendation the trust level will either remainunchanged or, if a pattern of ignoring recommendations from Andy isdetected, slightly the level of trust from Jim and Andy.

In some implementations, each user of the system has a “trustworthiness”score. The trustworthiness score represents an overall rating of thequality and usefulness of that user's recommendations. In someimplementations the trustworthiness score is represented by a numberbetween 0 and 1. In other implementations, the trust worthiness score isa value with a lower bound of 0, but no upper bound. In yet otherimplementations, the trustworthiness score could have a negative value.In this case, a respective user's trustworthiness score increases inresponse to indications that the respective user's recommendations aregood. For example, as users of the system chose to buy a product orservice in response to a recommendation from a particular user, thetrustworthiness score for the particular user would increase.Correspondingly, recommendations that are ignored or explicitly rejectedcould result in either no change of trustworthiness score or in alowered trustworthiness score.

In some implementations a higher trustworthiness score represents ahigher level of trustworthiness within the system. In someimplementations, if a user's trustworthiness score exceeds apredetermined level the user will be noted as a tastemaker or a veryinfluential user.

In some implementations, trust levels can be transitive between users.For example, if Jim trusts Pam with a trust level of 1 and Pam trustsMichael with a score of 0.75, the server system can calculate a trustlevel from Jim to Michael. In some implementations the server systemcalculates transitive trust by taking the trust level from Pam toMichael and discounting it by some fixed amount. For example, the trustlevel may be reduced by 5% for each level of removal from Jim. So Jim'strust level for Michael would be 0.75*0.95=0.7125. In someimplementations, transitive trust values are calculated before anyspecific need for those calculated values arrives. In otherimplementations, only direct trust values are stored in the trust graphsand transitive trust values are only calculated when required, such aswhen a request for a recommendation is received by the server system.

In some implementations transitive trust is calculated through multipleusers. For example, User A trusts User B, User B trusts User C, and UserC trusts User D. Transitive trust can be calculated for both Users C andD, and additionally for any users trusted by Users B, C, and D. In someimplementations transitive trust is calculated for as many other usersand through as many connections as possible. In other implementations,the server system limits the number of connections through which animplicit trust calculation is made. By limiting the number ofconnections (for example, no more than 10 connections) the server systemavoids using resources on very tenuous connections.

In some implementations the transitive trust calculations result in morethan one possible value of transitive trust from first user to a seconduser. For example, if user A trusts Users B and C, and both Users B andC trust User D, the value of the implicit trust calculation will dependon whether the connection is made through user B or user C. In someimplementations all possible trust levels are averaged to determine theactual implicit trust level. In other implementations the server systemselects either the highest or lowest trust level. In yet otherimplementations, the server system selects the implicit trust value thatrelies on the fewest number of connections. If multiple implicit trustvalues are tied for the fewest number of connections, the multiple trustvalues are averaged.

In some implementations, an aggregate trust value is calculated formultiple trust paths by using a probabilistic combination algorithm.Such an algorithm is AggregateTrustLevel=1−(1−p_(—)1)*(1−p_(—)2)*(1−p_n)where p_(—)1−p_n are trust levels from a plurality of different possibletrust paths. For example if one path gives a trust value of 0.8 andanother gives a trust value of 0.63, the aggregate trust level wouldequal 1−(1−0.8)*(1−0.63)=0.926. This function can be used for anarbitrary number of different trust paths.

In some implementations a trust indication from a first user to a seconduser indicates a specific category in which the indicated trust levelapplies. For example, Bob could trust Alice at a high level in onecategory of product, such as consumer electronics, but trust Alice at alow level for a second type of product, such as men's shoes. Thus, whenthe first user submits a trust indication of a trust level for thesecond user, the trust indication includes the category of product orservice for which the trust level applies. In this way the trust graphcan include different trust levels for different categories of products.In some implementations, the different categories are arranged in ahierarchical format. In some arrangement the highest hierarchical levelis a general level and there are a plurality of sub levels underneaththe top general level such as “fashion,” “electronics,” and “media”among others. Each sublevel has more specific sub levels under them. Forexample, the sublevel “fashion” could include the sublevels of “women'swear,” “men's wear” and “kid's wear.”

In some implementations, the server system can propagate trust levelsfrom a sub-level to hierarchical levels higher, more general categoriesin the hierarchy of categories and to lower, more specific categories inthe hierarchy of categories. In some implementations, trust scores arepassed to lower, more specific categories without alteration, but trustlevels are discounted when passed to higher, more general categories inthe hierarchy. For example, Jim trusts Andy 0.5 in the category “Shoes.”That score is propagated to lower, more specific categories, such as“Athletic shoes” or “Formal Shoes”, without discount. However, when thetrust level is propagated to higher, more general category, such as“Fashion,” the trust level is discounted by 10%. Thus, the graph woulddetermine that Jim trusts Andy in “Fashion” at the level of 0.45.

In some implementations, the server system uses the gathered trustinformation to improve a user's experience. The server system allowsusers to request recommendations for goods and services that the user isinterested in purchasing. The server system uses the stored trust graphsto identify trusted potential recommenders. The server system firstreceives a request for a recommendation from a first user. The requestfor recommendation includes a category of good or service that definesthe type of recommendation the first user wants. The server system usesthe trust graph associated with the first user, among other factors, todetermine a second user from whom to request a recommendation.

In some implementations, when a user first registers with the serversystem to participate in the online commerce system, the user has littleor no trust information regarding other users. The server system cancollect user information from other social networks (Facebook, Twitter,LinkedIn, etc) or from webmail address books to identify other users ofthe server system that the new user might wish to trust. The serversystem then displays trust recommendations to the user. In someimplementations, the server system only accesses the other socialnetwork information with the express permission of the user. In someimplementations, the server system can gather demographic informationfrom the new user and uses that demographic information (for example,user age and location) to determine recommended products and other usersthe potential new unit may wish to trust.

In some implementations, the server system uses the social network anddemographic information gathered from external sources, as describedabove, to determine recommendations from the user's social network priorto receiving adequate trust level information from the user. In someimplementations, the server system uses general product popularity datato find recommendations for users without sufficient trust information.General product popularity data is data that describes how popularparticular products are within their product category. In otherimplementations, the server system uses direct editorial control (aneditor selecting specific recommendations) to supply recommendationsprior to receiving adequate trust level information from the user.

In some implementations, the server system will identify one or moreusers not already trusted by a first user (User A) that the serversystem has determined are likely to be trusted by the first user. Insome implementations the server system identifies the one or more usersby finding connections or similarities between the one or more users andthe first user. For example, if multiple users trusted by the first userall trust a second user the server system determines that the first userwill be likely to trust the second user. In other implementations, theserver system will identify one or more users that have similaridentified interests as the first user or have recommended similarproducts to those recommended by the first user. In yet otherimplementations, the server system identifies one or more users likelyto be trusted by the first user using social connection information fromthird party websites or services, interactions that the users have hadwith the server system, and any other information the server system haswith regard to the users.

In some implementations, the server system identifies a particularcategory in which the first user is likely to trust the one or moreusers. In some implementations, the server system identifies one or moreusers likely to be trusted by the first user in response to a requestfrom the first user for recommendations of users to trust. In someimplementations, the server system transmits the identified one or moreusers to the first user for display. In some implementation the serversystem also transmits information describing the reasons why the serversystem selected a particular user that can be displayed either with therecommendation itself or at the request of the first user. For example,the server system transmits a recommendation for Bob to trust Ernie andincludes the fact that Ernie was identified because three people trustedby Bob (Alice, Carol, and Dan) also trust Ernie.

In some implementations, the one or more identified users arerecommended only in a particular category. In response to receiving arecommendation to trust a second user in a specific category, the firstuser can choose to trust the user only in the recommended category,trust the user in a narrower category than the recommended category, ortrust the user in a broader category than the recommended category. Forexample, the server system recommends that Bob trust Ernie in Men'sFormal Clothes. Bob has the option of trusting Ernie in only Men'sFormal Clothes, in a narrow category such as Men's Belts, or a broadercategory such as all Menswear. In some implementation, the first usercan request to view public information about the identified on or moreusers in determining whether to trust the user or not. In someimplementations, the first user can only see information that theidentified one or more users have explicitly marked as public. Forexample, Ernie may have made his recommendations in Menswear public, andBob can view the recommendations as part of his decision whether or notto trust Ernie.

In accordance with some implementations in response to receiving arequest for a recommendation, the server system determines a list ofusers in the first user's trust graph that have trust scores in thecategory requested by the user. The determined list has one or moreother users. The server system then ranks the one or more users in orderof trust level. In some implementations, the client system calculatestransitive trust values for users with whom the first user does not havea direct trust level and includes at least some of these users in thelist. Transitive trust values may also be pre-calculated and stored inthe server system. When a server system receives a request for arecommendation, the server system determines whether additionaltransitive trust values need to be calculated. In some implementations,only some transitive trust values are pre-calculated and others arecalculated as needed. For example, only first-order transitive trustvalues are pre-calculated and all other transitive trust values arecalculated as needed. First order transitive trust values that only haveone indirect trust link. For example, if Bob directly trusts Alice andCody, then the first order transitive trust values are calculated forthe users directly trusted by Alice and Cody.

The foregoing description, for purpose of explanation, has beendescribed with reference to specific implementations. However, theillustrative discussions above are not intended to be exhaustive or tolimit the invention to the precise forms disclosed. Many modificationsand variations are possible in view of the above teachings. Theimplementations were chosen and described in order to best explain theprinciples of the invention and its practical applications, to therebyenable others skilled in the art to best use the invention and variousimplementations with various modifications as are suited to theparticular use contemplated.

It will also be understood that, although the terms first, second, etc.may be used herein to describe various elements, these elements shouldnot be limited by these terms. These terms are only used to distinguishone element from another. For example, a first contact could be termed asecond contact, and, similarly, a second contact could be termed a firstcontact, without departing from the scope of the presentimplementations. The first contact and the second contact are bothcontacts, but they are not the same contact.

The terminology used in the description of the implementations herein isfor the purpose of describing particular implementations only and is notintended to be limiting. As used in the description of theimplementations and the appended claims, the singular forms “a,” “an,”and “the” are intended to include the plural forms as well, unless thecontext clearly indicates otherwise. It will also be understood that theterm “and/or” as used herein refers to and encompasses any and allpossible combinations of one or more of the associated listed items. Itwill be further understood that the terms “comprises” and/or“comprising,” when used in this specification, specify the presence ofstated features, integers, steps, operations, elements, and/orcomponents, but do not preclude the presence or addition of one or moreother features, integers, steps, operations, elements, components,and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon”or “in response to determining” or “in response to detecting,” dependingon the context. Similarly, the phrase “if it is determined” or “if (astated condition or event) is detected” may be construed to mean “upondetermining” or “in response to determining” or “upon detecting (thestated condition or event)” or “in response to detecting (the statedcondition or event),” depending on the context.

What is claimed is:
 1. A method, comprising: at a computer system having one or more processors and memory storing one or more programs for execution by the one or more processors: storing one or more vendor profiles, wherein each vendor profile is associated with a particular vendor and includes one or more vendor category scores; receiving a purchase request from a user of the server system, wherein the purchase request includes a product or service to be purchased; determining a vendor to supply the requested product based on the stored vendor profiles; purchasing the requested product from the determined vendor; and arranging for delivery of the purchased product or service.
 2. The method of claim 1, wherein determining a vendor to supply the requested product based on the stored vendor profiles includes: for each vendor in the plurality of vendors: generating a overall vendor score based on the one or more vendor category scores wherein the one or more vendor category scores are weighted based on the priority associated with each category; ranking the plurality of vendors based on the generated overall vendor score.
 3. The method of claim 2, wherein the priorities associated with the one or more vendor categories are predetermined by the computer system.
 4. The method of claim 2, further including: storing user profiles for each user of the computer system; wherein user profiles include priorities associated with vendor categories.
 5. The method of claim 1, further including: creating vendor profiles, wherein creating vendor profiles includes: determining one or more vendor scoring categories for one or more determined vendor categories, generating a vendor category score based on past vendor performance.
 6. The method of claim 5, wherein past vendor performance is based on user supplied feedback.
 7. The method of claim 5, wherein past vendor performance is determined based on data directly measured by the computer system.
 8. The method of claim 7, wherein the data measured by the computer system includes product delivery time, product price, and number of products in stock.
 9. The method of claim 1, includes receiving feedback from the user regarding the determined vendor; and updating the vendor profiles based on the received feedback.
 10. The method of claim 1, wherein the computer system includes a product database, and the method further includes: receiving a request to add a product to the product database, wherein the request includes a vendor associated with the product.
 11. The method of claim 10, wherein the request to add a product to the product database is a recommendation from a user.
 12. The method of claim 10, wherein the request to add a product to the product database is included in the purchase request.
 13. The method of claim 1, further including: prior to purchasing the requested product, sending a request to the user to confirm the determined vendor; and receiving a response from the user confirming the determined vendor.
 14. A server system for rewarding users in a social referral system, the server system comprising: one or more processors and memory storing one or more programs to be executed by the one or more processors; the one or more programs comprising instructions for: storing one or more vendor profiles, wherein each vendor profile is associated with a particular vendor and includes one or more vendor category scores; receiving a purchase request from a user of the server system, wherein the purchase request includes a product or service to be purchased; determining a vendor to supply the requested product based on the stored vendor profiles; purchasing the requested product from the determined vendor; and arranging for delivery of the purchased product or service.
 15. The server system of claim 14, further including instructions for: creating vendor profiles, wherein creating vendor profiles includes: determining one or more vendor scoring categories for one or more determined vendor categories, generating a vendor category score based on past vendor performance.
 16. The server system of claim 14, further including instructions for: receiving feedback from the user regarding the determined vendor; and updating the vendor profiles based on the received feedback.
 17. A non-transitory computer readable storage medium storing one or more programs configured for execution by an electronic device, the one or more programs comprising instructions for: storing one or more vendor profiles, wherein each vendor profile is associated with a particular vendor and includes one or more vendor category scores; receiving a purchase request from a user of the server system, wherein the purchase request includes a product or service to be purchased; determining a vendor to supply the requested product based on the stored vendor profiles; purchasing the requested product from the determined vendor; and arranging for delivery of the purchased product or service.
 18. The non-transitory computer readable storage medium of claim 14, further including instructions for: creating vendor profiles, wherein creating vendor profiles includes: determining one or more vendor scoring categories for one or more determined vendor categories, generating a vendor category score based on past vendor performance.
 19. The non-transitory computer readable storage medium of claim 14, further including instructions for: receiving feedback from the user regarding the determined vendor; and updating the vendor profiles based on the received feedback. 